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ENUM Validation Token Format Definition 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Abstract 


An ENUM domain name is tightly coupled with the underlying E.164 
number. The process of verifying whether the Registrant of an ENUM 
domain name is identical to the Assignee of the corresponding E.164 
number is commonly called "validation". This document describes a 
signed XML data format -- the Validation Token -- with which 
Validation Entities can convey successful completion of a validation 
procedure in a secure fashion. 
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Introduction 


In the case where an ENUM (E.164 Number Mapping [1]) domain name 
corresponds to an existing E.164 number [2], the delegation of this 
domain needs to be authorized by the Assignee of the corresponding 
E.164 number. In the role model described in [15], the entity that 
performs this check is called the Validation Entity (VE). 


By conveying an ENUM Validation Token -- a signed XML document -- to 
the Registry, a VE certifies that delegation requirements have been 
met and are current. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [3]. 


Data Requirements 


In this model, the Token is the only piece of data passed from the VE 
to the Registry. Therefore, the Token needs to contain at least as 
much information as the Registry requires to grant the delegation of 
the requested ENUM domain according to its registration policy. As 
such, the Registry will need confirmation that: 


o the Token was created by an accredited VE, 
o the Token’s duration of validity conforms to the policy, 


o the validation procedure employed has met minimum requirements as 
set forth by policy, 


o and that the Token is protected against tampering and replay 
attacks. 


Beyond such mandatory information, the Token may optionally include 
number holder information, in particular, to simplify future 
revalidations. 


For example, if initial validation requires the steps "Check the 
identity of the Registrant" and "Check the ownership of an E.164 
number", then a later revalidation only needs to re-check the 
ownership as the identity of the Registrant does not change. 


As the Token will be included (see e.g., [16]) in XML-based Registry/ 
Registrar protocols like the Extensible Provisioning Protocol (EPP) 
[13], it is a natural choice to use XML to encode Validation Tokens. 
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3. Digital Signature 


According to the architecture model the propriety of an ENUM 
delegation depends on the trust relationship between the Registry and 
the VE. In general, an untrusted link between the Registry and VE 
should be assumed (for instance, the Token is passed along with the 
registration request by a Registrar, who might have no role in 
asserting the right-to-use). Therefore, the Token must be protected 
against forgery, tampering, and replay-attacks. 


A digital signature on the token: 


o asserts that the token was indeed generated by the indicated VE 
(authenticity). 


o guarantees that the token was not tampered with in transit 
(integrity). 


o enables auditing the validation process (non-repudiation). 


The cryptographic signature on the token follows RFC 3275 (XML-DSIG 
[4]). As tokens might be transmitted as part of an already XML based 
protocol, the exclusive XML canonicalization [9] MUST be used. This 
transform guarantees that namespace declarations inherited from the 
surrounding XML do not invalidate the signature. In order to make 
the signature an integral part of the token, the 
"enveloped"-signature mode is employed. The signature covers all 
information contained in the Token. 


XML-DSIG offers a number of cryptographic algorithms for digesting 
and signing documents and recommends SHA1/RSA-SHA1. Recent advances 
in cryptanalysis have cast doubt on the security of SHA1, thus 
rendering this recommendation obsolete (see e.g., the Security 
Considerations of [14]). RFC 4051 [5] defines how additional 
algorithms can be used with XML-DSIG. 


Validation Entities MUST be able to sign tokens according to 
XML-DSIG, MUST support RSA-SHA1 and RSA-SHA256 [5], MUST support RSA 
key sizes of 1024 and 2048 bits, and MUST be able to embed X.509 [10] 
certificates. The Registry MUST define which signature algorithms 
and key sizes it will accept in Validation Tokens as part of its 
local policy. 


The choice of a RSA-based signature does not require a public key 
infrastructure. Whether the Registry acts as a certification 
authority, accepts certs from a public certification authority, or 
only accepts pre-registered keys is a local policy choice. 
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4. Field Descriptions 
The Validation Token is structured into three parts: the basic 
validation information, additional information about the Registrant, 
and the digital signature. The XML schema can be found in Section 6. 


4.1. The <validation> Element 


A token MUST contain a <validation> element that contains the 
following: 


o A single validation "serial" attribute identifying a validation 
token for a certain VE. It must be unique per VE. 


o A single <E164Number> element containing the underlying E.164 
number in fully qualified (international) format. 


o An optional <lastE164Number> element. If present, it indicates 
that the whole number block starting with <E164Number> up to and 
including <lastE164Number> has been validated. To avoid 
ambiguity, both numbers MUST be of the same length. 


o A single <validationEntityID> element identifying the VE. 


o A single <registrarID> element identifying the Registrar on whose 
behalf the validation was performed. 


o A single <methodID> element identifying the method used by the VE 
for validation. 


o A single <executionDate> attribute containing the date of 
validation formatted as "full-date" according to RFC 3339 [6]. 


o An optional <expirationDate> attribute marking the expiration date 
of the validation token formatted as "full-date" according to RFC 
3339. The Registry will automatically revoke the delegation at 
this date unless a new Token has been submitted that extends the 
lifetime of the validation. A missing <expirationDate> indicates 
infinite validity of the Token. 


The format and the uniqueness-constraints of these IDs is left to the 
local policy of the Registry. 
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4.2. The <tokendata> Element 


A token may contain a <tokendata> section containing information 
about the number holder, consisting of the following elements: 


o A single <organization> element containing the full name of the 
organization to which the Registrant is affiliated. 


o A single <commercialregisternumber> element. If the Registrant is 
a company, then this field can be used to uniquely identify this 
company by its official registration number within the local 
country. The interpretation of this field is thus 
country-specific. 


o A single <title> element. 
o A single <firstname> element. 
o A single <lastname> element. 


single <address> section containing the following elements: 
single optional <streetName> 

single optional <houseNumber> 

single optional <postalCode> 

single optional <locality> 

single optional <countyStateOrProvince> 


A 
EA 
EA 
EA 
EA 
EA 
E single optional <ISOcountryCode> 


PPP PS PS 


o Up to 10 <phone> elements containing full E.164 numbers. 
o Up to 10 <fax> elements containing full E.164 numbers. 
o Up to 10 <email> elements. 


All elements directly under <tokendata> are optional. The 
<ISOcountryCode> element specifies the country using the alpha-2 
country code from ISO 3166-1:2006 [11] (including updates published 
by the 3166 Maintenance Agency). The definition of the first five 
elements within the <address> element conforms to the second version 
of the E.115 Computerized Directory Assistance [17]. 


Lendl Standards Track [Page 5] 


RFC 5105 ENUM Validation Token December 2007 


5. Examples 
5.1. Unsigned Token without Registrant Information 


This basic Token without any information about the Registrant and 
without the cryptographic signature shows the basic layout of the 
Token. 


<?xml version="1.0" encoding="utf-8" standalone="no" ?> 
<token xmins="urn:ietf:params:xml:ns:enum-token-1.0" Id="TOKEN" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation= 
"urn:ietf:params:xml:ns:enum-token-1.0 enum-token-1.0.xsd"> 
<validation serial="acmeve-000002"> 
<E164Number>+442079460200</E164Number> 
<lastE164Number>+442079460499</lastE164Number> 
<validationEntityID>ACME-VE</validationEntityID> 
<registrarID>reg-4711</registrarID> 
<methodID>42</methodID> 
<executionDate>2007-05-08</executionDate> 
<expirationDate>2007-11-01</expirationDate> 
</validation> 
</token> 


5.2. Signed Token 


This example uses an X.509 based signature that includes the 
certificate of the signing validation entity. Thus, the validity of 
the signature can be verified without the need for a key-server. A 
valid signature is a necessary, but not sufficient, condition for a 
valid Token. Any entity evaluating a Token needs to check other 
factors as well, e.g., the certificate and the XML schema. 


<?xml version="1.0" encoding="utf-8" standalone="no" ?> 
<token xmins="urn:ietf:params:xml:ns:enum-token-1.0" Id="TOKEN" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation= 
"urn:ietf:params:xml:ns:enum-token-1.0 enum-token-1.0.xsd"> 
<validation serial="acmeve-000001"> 
<E164Number>+442079460123</E164Number> 
<validationEntityID>ACME-VE</validationEntityID> 
<registrarlD>reg-4711</registrarID> 
<methodID>42</methodID> 
<executionDate>2007-05-08</executionDate> 
</validation> 
<tokendata xmlns="urn:ietf:params:xml:ns:enum-tokendata-1.0" 
xsi:schemaLocation= 
"urn:ietf:params:xml:ns:enum-tokendata-1.0 enum-tokendata-1.0.xsd"> 
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<contact> 
<organisation>Example Inc.</organisation> 
<commercialregisternumber>4711</commercialregisternumber> 
<title>Dr.</title> 
<firstname>Max</firstname> 
<lastname>Mustermann</lastname> 
<address> 
<streetName>Main</streetName> 
<houseNumber>10</houseNumber> 
<postalCode>1010</postalCode> 
<locality>London</locality> 
<countyStateOrProvince>London</countyStateOrProvince> 
<ISOcountryCode>GB</ISOcountryCode> 
</address> 
<phone>+442079460123</phone> 
<email>mm@example.com</email> 
</contact> 
</tokendata> 
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
<SignedInfo> 
<CanonicalizationMethod 
Algorithm="http://www.w3.org/2001/10/xml-exc-cl4n#"/> 
<SignatureMethod 
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> 
<Reference URI="#TOKEN"> 
<Transforms> 
<Transform Algorithm= 
"http: //www.w3.org/2000/09/xmldsig#tenveloped-signature"/> 
<Transform 
Algorithm="http://www.w3.org/2001/10/xml-exc-cl4n#"> 
<InclusiveNamespaces 
xmlns="http://www.w3.org/2001/10/xml-exc-cl4n#" 
PrefixList="enum-token enum-tokendata"/> 
</Transform> 
</Transforms> 
<DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> 
<DigestValue 
>VxqsBxSNPFwPAUI1CHts3g3DehcexnBldqUz+GypLZ0k=</DigestValue> 
</Reference> 
</SignedInfo> 
<SignatureValue> 
OQKaphKRNPokVZFbenje+HZZV+RLrNweGnlWBw/ngAtH+rtuslR8LhMLmC4DlBb9v 
HvKIt1+7zLGm3VgYsqfHH8q3 jClimFxUIuLlIPqtpJs+xAHAJDzZt+vmsF/q2IgrsS 
KOuMmKuU5V1lgydDBOviIipcJx+PrPYyXYZS jOXkWknK8=</SignatureValue> 
<KeyInfo> 
<xX509Data> 
<x509Certificate> 
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MIIDZjJCCAs+gAwI BAgIBBDANBgkqhkiG9w0BAQOQFADBOMOQswCQYDVQQGEWJBVDEP 
MAOGA1UEBxMGVm1 lbm5hMROwWEgYDVOOKEwWtCTOZIIENlenRzLjEbDMBkKGAIUEAXMS 
QOVSVFMuYm9maC5weml2LmFOMSEwHwYJKoZIhveNAOkBFhJjZXJ0ec0Bib2ZolLnBy 
aXYuYXQwHhcNMDQWNz IwMTMxNTA5WhcNMDUWNz IwMTMxNTASW5jB/MOswCQYDVOOG 
EwJBVDEKMAgGA1UECBMBLTEPMA0GA1UEBxMGVm1 lbm5hMROwGwYDVOOKEXRBY211 
TEVOVU0gVmF saWRhdGlvb jEQMA4GA1UEAxMHYWNt ZS1WRTEiMCAGCSQGSIb3DQEJ 
ARYTbm9ib2R50GVudWOt YWNt ZS 5hdDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkC 
GgYEArJPejMFe54/zwztSdQXGxUtodJTOrlaGI21QPNjLvtPJg93+705SIOsZGSpg 
zWbztDAV5qc7PHZWUVIyf 6MbM5qSgQDVr JNRhTosNt yqmwi23BH52SKkX3P7eGit 
LmqgEkiUZRxZhZ6upRbt caqvKSwmxit vW4zXZhnkVHYJIZ2HuMcCAWEAAaOB/DCB+TAJ 
BgNVHRMEA j AAMCwGCWCGSAGG+EI BDOQOfFh1IPCGVUULNMIEdlLbmVyYXR1ZCBDZXJ0 
aWZpY2FO0ZTAdBONVHO4EF gQUyK4ot TOtvv6KdS1MBOPT5Vel 8JgwgZ4GA1UdIwSB 
1jJCBk4AUvfPadpm0HhmZx2iAVumOTwgnG2eheKR2MHOxC zAJBGNVBAYTAKFUMO8w 
DOYDVOQHEWZWaWVubmExFDASBgNVBAoTCOJUPRkggQ2VydHMuMRswGOQYDVQQDExJD 
RVJUUy5ib2ZoLnByaXYuYXOxITAfBgkqhkiG9IwOBCOEWEmN1cnRzOGJvZmgucHJp 
di5hdI IBADANBgkqhkiG9w0BAQOFAAOBgOCB9YCHBnIUhrdic4h5Ar4hdx jJHSOkDH 
sJWd+MYrNeuSrv3TIOsUkUgNepNNhmkZPtiXgqfy3388IRdJtJiLWXSOb/X1ZHOMO9I 
MvwKYwhepQO9UdM/w7VpXQaf +CEjJOXSyaxGw65UsHIOijgiG/WyhSj+Lzriw/CTge 
P2iAJkJVC4t2XA== 

</X509Certificate> 

</X509Data> 

</KeyInfo> 

</Signature> 

</token> 


6. Formal Syntax 


The formal syntax of the validation token is specified using XML 
schema notation [7] [8]. Two schemas are defined: The "token core 
schema" contains mandatory attribute definitions, and the "token data 
schema" defines the format of the optional "tokendata" section. The 
BEGIN and END tags are not part of the schema; they are used to note 
the beginning and ending of the schema for URI registration purposes. 
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6.1. Token Core Schema 


BEGIN 
<?xml version="1.0" encoding="UTF-8"?> 


<schema targetNamespace="urn:ietf:params:xml:ns:enum-token-1.0" 
xmlns:enum-token="urn:ietf:params:xml:ns:enum-token-1.0" 
xmlns:enum-tokendata="urn:ietf:params:xml:ns:enum-tokendata-1.0" 
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<!-- Import common element types. --> 


<import namespace="http://www.w3.org/2000/09/xmldsig#" 
schemaLocation="xmldsig-core-schema.xsd"/> 

<import namespace="urn:ietf:params:xml:ns:enum-tokendata-1.0" 
schemaLocation="enum-tokendata-1.0.xsd"/> 


<annotation> 
<documentation> 
Validation Token core schema 
</documentation> 
</annotation> 


<element name="token" type="enum-token:tokenBaseType"/> 


<simpleType name="shortTokenType"> 
<restriction base="token"> 
<minLength value="1"/> 
<maxLength value="20"/> 
</restriction> 
</simpleType> 


<simpleType name="el64numberType"> 
<restriction base="token"> 
<maxLength value="20"/> 
<pattern value="\+\d\d*"/> 
</restriction> 
</simpleType> 


<complexType name="validationDataType"> 
<sequence> 
<element name="E164Number" 
type="enum-token:el64numberType"/> 
<element name="lastE164Number" minOccurs="0" 
type="enum-token:el64numberType"/> 
<element name="validationEntityID" 
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type="enum-token: shortTokenType"/> 
<element name="registrarID" 
type="enum-token: shortTokenType"/> 
<element name="methodID" 
type="enum-token: shortTokenType"/> 
<element name="executionDate" type="date"/> 
<element name="expirationDate" 
type="date" minOccurs="0"/> 
</sequence> 
<attribute name="serial" type="enum-token:shortTokenType" 
use="required"/> 
</complexType> 


<complexType name="tokenBaseType"> 
<sequence> 
<element name="validation" 
type="enum-token:validationDataType"/> 
<any namespace="urn:ietf:params:xml:ns:enum-tokendata-1.0" 
minOccurs="0"/> 
<any namespace="http://www.w3.org/2000/09/xmldsig#"/> 
</sequence> 
<attribute name="Id" type="ID" use="required"/> 
</complexType> 
</schema> 
END 


6.2. Token Data Schema 


BEGIN 
<?xml version="1.0" encoding="UTF-8"?> 


<schema targetNamespace="urn:ietf:params:xml:ns:enum-tokendata-1.0" 
xmlns:enum-tokendata="urn:ietf:params:xml:ns:enum-tokendata-1.0" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<element name="tokendata" type="enum-tokendata:tokenDataType"/> 


<simpleType name="E115String"> 
<restriction base="string"> 

<pattern value="[&#x20;-&#xX7A; &#xXA0; -—G#XD7FF; &#xXE000; -G#XFFFD; ]*"/> 
</restriction> 

</simpleType> 


<simpleType name="E115StringUb256"> 
<restriction base="enum-tokendata:E115String"> 
<minLength value="1"/> 
<maxLength value="256"/> 
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</restriction> 
</simpleType> 


<simpleType name="countryCodeType"> 
<restriction base="token"> 
<minLength value="2"/> 
<maxLength value="2"/> 
</restriction> 
</simpleType> 


<simpleType name="TokenType"> 
<restriction base="token"> 
<minLength value="1"/> 
<maxLength value="64"/> 
</restriction> 
</simpleType> 


<complexType name="addressType"> 


<all> 
<element name="streetName" minOccurs="0" 
type="enum-tokendata:E115StringUb256" /> 
<element name="houseNumber" minOccurs="0" 
type="enum-tokendata:E115StringUb256"/> 
<element name="postalCode" minOccurs="0" 
type="enum-tokendata:E115StringUb256"/> 
<element name="locality" minOccurs="0" 


type="enum-tokendata:E115StringUb256"/> 
<element name="countyStateOrProvince" minOccurs="0" 
type="enum-tokendata:E115StringUb256"/> 
<element name="ISOcountryCode" minOccurs="0" 
type="enum-tokendata:countryCodeType"/> 
</all> 
</complexType> 


<group name="tokenContactBaseGroup"> 
<sequence> 
<element name="organisation" minOccurs="0" 
type="enum-tokendata:E115StringUb256"/> 
<element name="commercialregisternumber" minOccurs="0" 
type="enum-tokendata:TokenType"/> 


<element name="title" minOccurs="0" 
type="enum-tokendata:TokenType"/> 

<element name="firstname" minOccurs="0" 
type="enum-tokendata:E115StringUb256"/> 
<element name="lastname" minOccurs="0" 
type="enum-tokendata:E115StringUb256"/> 
<element name="address" minOccurs="0" 


type="enum-tokendata:addressType"/> 
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<element name="phone" type="enum-tokendata:TokenType" 
minOccurs="0" maxOccurs="10" /> 
<element name="fax" type="enum-tokendata:TokenType" 
minOccurs="0" maxOccurs="10" /> 
<element name="email" type="enum-tokendata:TokenType" 
minOccurs="0" maxOccurs="10" /> 
</sequence> 
</group> 
<complexType name="contactType"> 
<sequence> 
<group ref="enum-tokendata:tokenContactBaseGroup"/> 
</sequence> 
</complexType> 
<complexType name="tokenDataType"> 
<sequence> 
<element name="contact" type="enum-tokendata:contactType"/> 
</sequence> 
</complexType> 
</schema> 
END 
Other Applications of the Token Concept 


The concept of the validation token may be useful in other 
registry-type applications where the proof of an underlying right is 
a condition for a valid registration. 


An example is a Top Level Domain (TLD) where registration is subject 
to proof of some precondition, like a trade mark or the right ina 
name. Such situations often arise during the introduction of a new 
TLD, e.g., during a "Sunrise" phase. 


A Number Portability (NP) database faces very similar verification 
issues. An NP system based on the Token concept could potentially be 
superior to current methods, and aid in the convergence of NP and 
ENUM. 


IANA Considerations 


This document uses Uniform Resource Names (URNs) to describe XML 
namespaces and XML schemas conforming to a registry mechanism 
described in RFC 3688 [12]. IANA has made the following four URI 
assignments. 
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1. Registration for the Token namespace: 
* URI: urn:ietf:params:xml:ns:enum-token-1.0 
* Registrant Contact: See the "Author’s Address" section of this 


document. 
* XML: None. Namespace URIs do not represent an XML 
specification. 


2. Registration for the Token XML schema: 
* URI: urn:ietf:params:xml:schema:enum-token-1.0 
* Registrant Contact: See the "Author’s Address" section of this 
document. 
* XML: See Section 6.1 of this document. 


3. Registration for the Token Data namespace: 
* URI: urn:ietf:params:xml:ns:enum-tokendata-1.0 
* Registrant Contact: See the "Author’s Address" section of this 


document. 
* XML: None. Namespace URIs do not represent an XML 
specification. 


4. Registration for the Token Data XML schema: 
* URI: urn:ietf:params:xml:schema:enum-tokendata-1.0 
* Registrant Contact: See the "Author’s Address" section of this 
document. 
* XML: See Section 6.2 of this document. 


The IDs used in the validationEntityID, RegistrarID, and methodID 
elements are subject to local policy and thus do not require IANA 
registration. 


9. Security Considerations 


The security of the Validation Token depends on the security of the 
underlying XML DSIG algorithms. As such, all the security 
considerations from [4] apply here as well. Two points from [4] 
merit repetition: 


Transforms are used to select the relevant data for signing and 
discarding irrelevant information (e.g., pretty-printing and 
name-space local names). 


The <Reference URI="#TOKEN"> element and attribute combined with the 
Id="TOKEN" attribute in <token> specifies that the signature should 

cover the complete token. Moving the Id="TOKEN" attribute to e.g., 

the <tokendata> element would make the signature worthless. 
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10. 


da 


EE; 


It is thus critical that the Registry not only checks whether the 
Token passes a generic XML-DSIG signature check, but also that: 


1. the signature uses approved transforms and cryptographic 
algorithms. 

2. the signature references the <token> element. 

3. the key used in the signature belongs to an accredited VE. 


The Token content is not encrypted. If local policy dictates that 
the information contained within the token should be confidential, 
then this has to be handled through a different mechanism. 


When processing a delegation request, the Registry MUST verify that 
the information contained in the Token matches the delegation 
request. The <registrarID> element in the Token prevents a malicious 
second Registrar from using an eavesdropped Token to register a 
domain in his name. The Registry MUST verify that the 
<expirationDate> given (including the case of no given expiration 
date) conforms to the Registry’s policy. To avert replay attacks, 
local policy MUST specify how long after <executionDate> the Token 
can be used to authorize a delegation. 
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